we should clean this up - can be in a later PR. the ts_devserver should have an option that allows us to serve additional rootdirs, I think this is already present but maybe not wired up?

we need an actual example app. I'll ask in the GDE channel to see if we can get something good

if we check this in, it needs a bunch of comments explaining what this is, how to use it, how to formulate one for a different library, etc. - since this is the canonical example

I will add some comments

I'm not sure this merits a whole separate bazel package - why not put the shim in something like typings.d.ts in the src/ directory?

That would work. I like having them in their own folder but a single typings.d.ts file will do the trick.

I feel like this is the opposite of what we want, long-term -- we want users to import d3 if they use it, so that taze can add the proper dependency when needed.

Alex and I both agree that we need another example with d3 imported properly. This example is the only way that works at the moment with where ts_devserver and the rollup_bundle production bundler is at right now. Getting it to work with an import will require changes to both and needs to some thought.

@evmar my understanding is that some libraries are documented such that developers expect to import them, but some are only accessible via globals. I think ABC needs to demonstrate both ways? If we only document how to use ES imports then I think some libraries would be unusable?

I think the typings usually match how the library works, so you only need a shim thing like here when you're using the library in a way contrary to its intended use.

@gregmagolan I'm hesitant to merge this if the intended use of d3 is to import it.
What's a library that provides a better test case for ambient imports?

I don't know of one off the top of my head. I'll think about it.